In distributed client-server environments in which one or more client devices or machines (clients) interact with an application (i.e., a computer software program written to perform particular functions in accordance with client interaction) in association with one or more server devices or machines (servers), it is known that such servers often become overloaded. It is also known that long network delays often result between clients and servers in distributed systems since paths between clients and servers involve wide area networks formed across geographically separated portions of the system.
This is also the case in the J2EE (Java 2 Platform Enterprise Edition from Sun Microsystems) environment. As is known, the J2EE environment is a three-tier environment. User machines form one tier, an enterprise's (e.g., company, organization, etc.) database servers and legacy information systems (back-end servers) form another tier, and application servers form a middle tier between the user machines and the back-end servers. In the J2EE environment, an application server contains both Enterprise JavaBean (EJB) clients and EJB servers, typically in the same address space in the same machine. The EJB servers are considered “database clients” (e.g., so-called Java Database Connectivity (JDBC) clients) of the back-end servers. Thus, as is known, the back-end servers in the J2EE environment also become increasingly overloaded, because it is much more difficult to replicate the back-end servers than to replicate the application servers.
In addition, Internet-based distributed systems usually involve some high-latency paths where communication occurs between geographically distributed system components. Typically the high-latency path is between the user and the application server, although “edge server” architectures move some or all of the application server near the user (e.g., to the Internet Service Provider), which places the high-latency path between the application server and the back-end servers.
As a result of both of these reasons, application performance decreases since a client (e.g., EJB server or otherwise) must typically access the back-end server whenever the client needs data.
Furthermore, it is known that transactions associated with applications created for the J2EE environment, similar to CORBA (Common Object Request Broker Architecture from the Object Management Group) transactions, attempt to satisfy the so-called ACID (Atomic, Consistent, Isolated, Durable) properties as described in J. Gray et al., “Transaction Processing: Concepts and Techniques,” Morgan Kaufmann, 1993. Thus, a transaction may employ semantics that serve to satisfy the ACID properties such that the transaction is considered to be atomic (e.g., all or nothing), consistent (e.g., no interim state of the data), isolated (e.g., does not affect or is not affected by other transactions) and durable (e.g., will complete if system fails or can be reversed).
Without transactional semantics, concurrent clients will “step on” one another's data modifications with respect to an application. However, existing application approaches provide very strict isolation between transactions, e.g., so-called “serializable” or “degree-3” isolation. In particular, this is the case with existing caching approaches. Such strict isolation can further add to performance problems between clients (e.g., EJB servers) and servers (e.g., back-end servers).
Accordingly, there is a need for techniques which enable relaxed transactional isolation and optimistic concurrency control in a distributed client-server architecture, and which address the problems of server overloading and network delays known to exist in conventional distributed client-server architectures.